A Methodology for Developing Agent Based Systems for Enterprise Integration

Potentially one of the most significant opportunities for enterprise integration is the recent development and advancement of agent based systems. However, before agents can be used as generic building blocks, a methodology must be established for the development of these systems. This methodology must encompass modelling, design, and implementation of the systems. This paper outlines a methodology for the software engineering of agent based systems. The methodology is based upon the IDEF (ICAM Definition) approach for workflow modelling and analysis, the CIMOSA enterprise modelling framework, and the use case driven approach to object oriented software engineering. The methodology is illustrated via a case study in the area of discrete parts manufacturing. 1.0 INTRODUCTION Potentially one of the most significant opportunities for enterprise integration is the recent advancement of agent based systems. Numerous examples can be found in the literature of applications of agent based systems to enterprise integration (Pan and Tenenbaum, 1991); concurrent engineering (Cutkosky and Engelmore, 1992), (Tenenbaum, Weber, and Gruber, 1992), and (Olsen, Cutkosky, Tenenbaum, and Gruber, 1994); and manufacturing (Kwok and Norrie, 1993). These systems exhibit significant advances in distributed problem solving. Before agents can be used widely used for enterprise engineering, a methodology must be established for the development of agent based systems. The need for software engineering methodologies for agent based systems has been described elsewhere (Huntbach, Jennings, and Ringwood, 1995). Software engineering is the establishment and use of engineering principles to obtain economical software that is reliable and works efficiently on real machines (Pressman, 1992). Work by (Huntbach, Jennings, and Ringwood, 1995) indicated that an agent could be identified as a process or a data store in a data flow diagram with real time extensions and by a decision table (Cohen and Ringwood, 1995). Agent behavior is actually quite different from a data flow process or a data store. The need to consider work flow and not just data flow (Klein, M., 1995) for agents has been discussed, as agents cooperate much as individuals do in organizations or enterprises. (Klein, M., 1995) provides the following table for a comparison of dataflow and workflow representations, and it is evident that workflow representations are more suitable. Dataflow Workflow Communication between computer systems Business processes with human participants Pass information Pass tasks Pre-defined and rigid Can have exceptions First in First Out queues Task queues, reasoning about ordering/ merging Systems are interchangeable Agents have unique skills and positions Requires input data Requires task execution environment In this paper, existing methodologies for workflow and object oriented analysis and design are extended to encompass agent oriented systems. The research proposes that as agents must be implemented in software, a workflow representation alone can not be used. An object oriented software engineering methodology is employed, but many aspects of the object oriented model have an equivalent workflow representation that is discussed. In particular, the IDEF methodology for integrated computer aided manufacturing (ICAM), the CIMOSA modelling framework for enterprise engineering, and the use case driven object oriented software engineering (OOSE) approach are utilized. These tools have been employed because they capture the work flow and active nature of an agent system. They are also mainstream approaches that are widely used for analysis, design, and implementation. 2.0 BACKGROUND 2.1 Agents 2.1.1 Definitions There are two views of agents: weak and strong (Wooldridge and Jennings, 1995). A weak definition of agency is items i) through iv) while a strong definition adds one of v) through vii) below: i) autonomous agents operate without direct intervention ii) social agents interact with other agents iii) reactive agents perceive their environment and respond to changes that occur iv) proactive agents affect their environment rather than passively allowing their environment to affect them v) mentalistic notions an agent has knowledge, and desires, intentions, commitments, and choices (proactive behavior) vi) rationality an agent performs actions which further its goals vii) veracity and viii) adaptability or learning. Strong agents are also termed reflective in that they reflect on their behavior rather than merely reacting to stimuli or changes. Strong agents are emphasized in this research, although only items i) through vi) above are considered; veracity and learning are not addressed. Strong agents reason about their beliefs to select a plan that could achieve their stated goals. Beliefs in reflective agent oriented systems are primarily represented in extensions to first order predicate calculus. Two examples are dMARS (Distributed Multiagent Reasoning System) (Georgeff, Ingrand, et. al) (Brenton, 1995) and KIF (Knowledge Interchange Format) (Genesereth, Fikes, et. al, 1992). Agent pro-active behavior is represented in terms of a plan library. An agent selects a plan from the plan library on the basis of the goals that are to be accomplished; goals represent states of affairs that an agent wants to achieve, test for, or maintain (Georgeff and Rao, 1995). A plan is instantiated when a triggering event occurs that satisfies its invocation and context conditions, such as the posting of a new goal. An instantiated plan is an intention. The body of a plan is a set of tasks that can be subgoals, actions, assertions to and retractions from the belief database, and queries and messages to other agents. When an intention is formed, these tasks are executed by the agent in an effort to reach the stated goal. 2.1.2 Agent Cooperation Agents operate in a distributed environment; therefore, agents require mechanisms and behavior that allow them to communicate with other agents. KQML (Knowledge Query and Manipulation Lanugage) (Finin, Weber, et al, 1993) is a language for communication among agent based programs. With KQML, agents can query for and offer information, along with other options. Agents must cooperate and negotiate with each other. When agents negotiate, they engage in conversations that can be represented in speech acts and state machines. Languages have been developed to support this. COOL is an extension to KQML (Barbuceanu and Fox, 1995), and with it agents can make proposals and counterproposals, accept and reject goals, and notify other agents of goal cancellation, satisfaction, or failure. Another language, AgenTalk (Kuwabara, Ishida, and Osato, 1995), has an inheritance or specialization mechanism for introducing new protocols as extensions of predefined ones. Related work by (Dunskus et al., 1995) has resulted in a preliminary categorization of the basic types of agents. Selectors, Estimators, Evaluators, Critics, Praisers, and Suggestors have been considered as narrow scope, or single function agents. This approach is valuable in that it addresses given applications at a more abstract level and allows new problems to be viewed as extensions or specializations of problems that have been seen before. Basic types of negotiation between these agents, in particular conflict resolution (Klein, 1991), have also been identified. 2.2 Object Oriented Software Engineering 2.2.1 Definition In a complete view, the notion of an object encompasses all of the following features (Booch, 1994): 1. Compound objects an object can have properties or attributes that are in fact objects themselves. 2. Inheritance an object type can have subtypes (classes can have subclasses). 3. Encapsulation an object can hide or protect data and behavior 4. Identity a system can distinguish between two objects that “look” the same. 5. State an object’s behavior is dependent on its history 6. Behavior an object can act and react through receiving and sending messages 2.2.2 Object Oriented Analysis During object oriented analysis, an object oriented model is developed for a given application. The Object Modelling Technique (OMT) (Rumbaugh et al., 1991), consists of three complementary models: the object, dynamic and functional models. The object model indicates objects and relationships between objects. The dynamic model includes scenarios and event traces of object interactions. The functional model resembles a data flow diagram, with passive objects as data stores. State transition diagrams are used to provide an overall view of an object’s dynamic behavior and to gain insight into inheritance. Subclasses inherit the state diagram of a superclass, adding states and transitions. Therefore, the protocols of AgenTalk (section 2.1.2) are in fact objects that can be specialized using inheritance, as stated in (Kuwabara, Ishida, and Osato, 1995). In the use case approach, also called OOSE (Object Oriented Software Engineering) (Jacobson, 1992), a use case is a scenario or a description of how users interact with the system in a certain mode of operation. A user in a particular role is known as an actor, and each actor uses one or more use cases. Objects relevant to a use case are identified, and their dynamic behavior is analysed. One use case can extend another one, meaning that it is inserted into the first use case, adding to its definition. Extend relationships can be conditional, occurring under only certain circumstances. Use cases can also be described at varying levels of abstraction, and inheritance can be utilized to provide specialization. A use case may be purely abstract, or it may be concrete and therefore able to be instantiated. 2.3 Enterprise Modelling Methodologies Methodologies have been proposed for enterprise modelling. The IDEF (ICAM Definition) method (Bravoco and Yadav, 1985a and 1985b) is a standard for requirements definition in manufacturing and other organizations. IDEF comprises three modeling methodologies: the function model (IDEF0), information model (IDEF1), and dynamic model (IDEF2). In the function model, the manufacturing or other organization is described in terms of a hierarchy of decisions, activities, or actions. Each function is given an ICOM (Input, Control, Output, and Resource or Mechanism) representation. The CIMOSA modelling framework (Computer Integrated Manufacturing Open System Architecture) (Kosanke, 1992) centers on types of major constructs. In CIMOSA, an enterprise activity is analogous to an IDEF function, except it can have control input and output, and resource or mechanism input and output. Both the CIMOSA and IDEF0 models can be taken to a high degree of detail, as shown in Figure 1. Here, an IDEF0 function includes decisions that are made on the basis of control input. Decide Action chooses a method or activity (Method 1 or Method 2), based upon the Input and the Control Input. F u n c t io n A 1 In p u t C o n t ro l In p u t O u tp u t D e c id e a c t io n M e th o d 1 M e th o d 2 A c t io n 1